Skip to content

Graphing It Out

In the previous lesson, we explored the performance implications of various data-fetching strategies using the “Performance” tab of the Chrome developer tools.

Screenshot of the Chrome developer tools' “Performance” tab

This view is powerful indeed, but it can definitely feel overwhelming. It also doesn't tell the full story, since it doesn't know what's happening on the server.

I took the liberty of creating an interactive graph that shows the flow of events across 3 different strategies:

  1. Traditional server-side rendering.
  2. Doing a light server-side render, and then fetching the data on the client with SWR.
  3. The fancy new solution using Suspense and Streaming SSR.

Spend a few moments exploring these strategies in the graph. Afterwards, I'll walk you through it, and (hopefully) answer any questions you have about it!

Classic Server Side Rendering

This is a data visualization which shows a sequence of events between client and server. Each event is represented here as a list item.

  1. "Database Query" on server. Duration: 12 units of time.
  2. "Render App" on server. Duration: 4 units of time.
  3. Response from server. Duration: 4 units of time.
  4. "Download JS" on client. Duration: 6 units of time.
  5. "Hydrate" on client. Duration: 4 units of time.

Graph walkthrough

Video Summary

This video walks through the 3 different strategies shown in the graph, explaining exactly what each step represents, and how things vary between strategies. It would be difficult to transcribe.

This video also explains something mentioned briefly in the previous lesson: Streaming SSR.

In the “Suspense with Streaming SSR” version, our initial request sends two separate HTML chunks:

Screenshot showing the two “render” steps in the Suspense graph

This works because React is taking advantage of a super-power that web servers have: the ability to send the response in chunks. This is known as streaming.

It's the same fundamental idea as video streaming. When you watch a video on this course platform, you don't have to wait for the entire video to be received before you can start watching. The server sends the data in chunks.

React does something similar. It generates and sends the initial layout HTML with the skeleton placeholder, but it doesn't end the request there. Instead, it continues working to generate the rest of the HTML, the grid of shoes with real data.

Essentially, by sending multiple chunks of HTML, we're able to gain the benefits of both other approaches:

  • Like the “SWR” approach, we're able to load the initial UI very quickly, without waiting for the slow database query
  • Like the “Classic SSR” approach, we're able to show the full set of sneakers in a reasonable amount of time, by doing that work in parallel.